A range query against a nullable numeric field raises instead of returning False:

NumericQuery("rg_track_gain", "-10..0").match(Item())
TypeError: '<' not supported between instances of 'NoneType' and 'int'

NumericQuery.match() compares the value against rangemin/rangemax with no None guard. Nullable types (NullFloat, NullInteger) use None as their null value — unlike Integer/Float, whose null is 0, which is why year queries never hit this and the bug stayed hidden. Affected fields: album_id (None for every singleton) and the whole rg_* / r128_* family (None until ReplayGain has been run, i.e. by default). Point queries (rg_track_gain:5) were already fine — only the range branches.

What the correct behaviour is

The query's own col_clause() defines it: rg_track_gain >= ? AND rg_track_gain <= ? against NULL is never true in SQL, so the row is quietly excluded. match() should agree — this is the classic SQL-path/match-path divergence, and test_fast_vs_slow in the test file exists precisely to pin that contract (it just never covered a nullable field).

Reachability

Two callers, and the first has no SQL path at all:

• library/models.py:1203 — Item.destination() evaluates paths: config rules through match() unconditionally. A rule like rg_track_gain:0.. crashes on any item lacking ReplayGain. Verified end-to-end:

  item.destination(path_formats=[("rg_track_gain:0..", "loud/$title"), ("default", "$title")])
  # TypeError

• dbcore/db.py:805 — the Results slow path, used whenever clause() returns None (any flexattr subquery forces this). beet ls "rg_track_gain:0.. someflex:x" raises, while the same data through a fast SQL-only query returns [] cleanly.

Precedent

This is the sibling of #3461. Commit 2293d2f6 ("Fix crash when sorting by a nullable field missing on some items") fixed the identical None-comparison crash on the sort side — sort.py deliberately groups nulls together "matching SQLite's default ordering of NULLs", and its comment names NullInteger/NullFloat explicitly. The query side was missed.

Tests

Three cases (-10..0, 0.., ..0) asserting a range never matches a null value. All fail on master with the TypeError and pass here. No existing test fed a nullable field to NumericQuery — test/dbcore/test_query.py only uses year.

• pytest test/dbcore/test_query.py — 146 passed (143 baseline + 3 new)
• pytest test/test_library.py test/dbcore/ — 518 passed, no regressions
• ruff check / ruff format --check / mypy clean; changelog checked with docstrfmt, sphinx-lint, and the unreleased-section check.

AI disclosure: drafted with Claude Code (Opus 4.8), including the root-cause trace and the tests. I ran the repro and the test suite locally and reviewed the diff before opening.